1. Field of the Invention
The present invention relates generally to consumer electronic devices. More specifically, the present invention relates to using an input device to control a different device.
2. Description of the Related Art
Input devices, such as touchpads, mice, microphones, keyboards, etc. are typically either built into or directly connected to the devices they control (e.g., a tablet computer, mobile phone, or personal computer). The result is that the input device winds up being exclusively allocated to the particular device it is connected to. Recently, the popularity of device-capable wireless standards, such as Bluetooth®, has enabled an input device to be paired with a controlled device via a wireless connection. Nevertheless, the Bluetooth® device winds up being exclusively allocated to the controlled device, at least as long as the Bluetooth® pairing remains in effect. Pairing a Bluetooth® device with another Bluetooth® device requires that the user enter input on both devices to facilitate the pairing (on one of the devices a “Bluetooth® detection” mode must first be entered and then on the other device the user must select the particular device to connect to and/or enter an input code).
It would be beneficial, however, if there would be some way to dynamically allocate the input device to a device to be controlled. This is especially true in a home network, where a user may own many devices that have the capability to interact with one another. For example, a tablet computer may be configured to control a digital television, or voice analysis software on a mobile phone could be used to navigate menus on a digital television. This control could even operate in the other direction, with a user controlling a mobile device using, for example, a television.
Universal Plug and Play (UPnP) is a distributed, open networking architecture that allows devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and corporate environments. UPnP achieves this by defining and publishing UPnP device control protocols built upon open, Internet Engineering Task Force (IETF)-based communication standards.
UPnP has grown in popularity of late in part due to the rise in popularity of media servers. Media servers are small computers that store multiple types of content (e.g., photos, music, videos, etc.). The content may then be streamed from a media server to one or more control points (e.g., mp3 player, television set, etc.). These media servers have proven quite popular and have led the way towards more and more people establishing home networks of various types of devices in their homes and/or businesses.
UPnP communications, however, are not limited to media servers, and as the number of UPnP enabled devices in the home grows, there is more and more opportunity to allow different types of communications between the devices. While UPnP contains an ability to have one UPnP device send input commands to another device, it only does so by a guaranteed service wherein the controlling device keeps sending each input command to the controlled device over and over again until it is sure that the input command is received. In such instances, the repeated communications, possibly even unnecessary, can clog the communications stream. This slows the process down significantly, and in fact this UPnP-based input command transfer is too slow to perform the time-sensitive type of input command transfer that is needed in order to allow a user to, for example, control a menu on a television.
Users are used to having commands on many types of consumer devices, such as televisions, executed immediately upon pressing the button. The user experience would be severely degraded by using UPnP to communicate input commands, as what would ordinarily be a command that is executed immediately upon depressing a key could take as long as a few seconds, causing the user's next command to be entered prior to seeing any visual feedback from the first command, and thereby causing the user to get confused when entering a multi-command sequence. For example, a user may enter the commands to navigate “up”, “left”, and then “select” prior to even receiving any visual feedback that the “up” command has been executed (such as the cursor moving upwards on the screen). This may cause the user to assume that the “up” command was not even received, and thus he may enter it again, perhaps in the middle of an input sequence. This can wreak havoc on a sequence of commands to be entered by a user and contributes to a negative user experience with the device.
What is needed is a solution that addresses these issues